1. Field of the Invention
The invention is related to a method for integrated data handling in a plant which is engineered and operated by a plurality of software applications having different functionalities, comprising interconnecting the software applications via a communication framework and mechanism.
Although in the following the invention is exemplified by a power plant, it is by no means restricted to power plants, but can be applied in any kind of plant.
2. Description of the Related Art
A power plant is a technical system that is built to execute a power generation process. The power generation process is a hierarchical process that uses hardware (e.g., field devices, pumps or a conveyer belt) to transform energy with the ultimate goal of generating electrical power. The operation, monitoring and controlling of the power plant is performed by an automation system respectively by humans. For this purpose, a multitude of heterogeneous software applications that realize the automation logics (e.g., automatic control loops), the possibilities for operator interactions etc. are required. Such software applications include, e.g., a distributed control system (DCS), an asset management system or a fleet control system.
One can distinguish two major phases: (1) the engineering phase and (2) the operation phase. It should be noted the tasks within the two phases are fundamentally different. The engineering phase includes the configuration of hardware setup, logics, or process parameters by using corresponding software applications. The plant erection and commissioning is also considered to be part of this phase. The operation phase includes operation and control of the power generation process at runtime. It should be noted that both phases are strongly connected, because the result of the engineering phase (i.e., the configuration of the hardware setup and logics) is required during the operation phase to run the plant operation process.
The fundamental differences between the tasks of the two phases are also reflected in the software applications. Thus, for both phases, a multitude of heterogeneous software applications for different aspects exists. Examples for different aspects in the engineering phase are hardware, software, and field-device engineering. In the operation phase, the aspects to be considered are monitoring, operation and control of the plant or even plant and fleet management and optimization. Some software applications are designed either for the engineering or the operation phase only. However, it should be noted there are also combined software applications, which support aspects of both the engineering phase and the plant operation phase (e.g., applicant's Siemens DCS SPPA-T3000). Different software applications have to use the same data. As a result, they need to be able to communicate within one phase (i.e., within the engineering or operation phase) as well as across both phases (i.e., the results of engineering need to be communicated to operational systems in the form of configuration data, but also vice-versa, for example, in case of a plant modernization project).
A consequence of such a heterogeneous software application landscape is that data related to the same item of a plant (e.g., data related to a water pump) is typically represented in multiple software applications. This is true for the engineering phase alone (e.g., configuration of data related to a water pump resides both in the hardware as well as the software engineering application) as well as for the operation phase alone (e.g., the operation time of a water pump is stored both in the distributed control system as well as in the asset management system) but also across both phases (e.g., the configuration data of a water pump is relevant for the operation of the distributed control system). Note that due to the loose coupling of the different software applications inconsistencies may occur, which are hard to detect due to several reasons: (1) variables representing the same data may be named differently, (2) variables representing different data may have the same names or (3) variables representing the same data are named identically, but their values are encoded in different encoding systems.
There is no standard data model in the power generation domain. As a result, the software applications described above typically have different internal data models. For data exchange between software applications, data model converters are therefore needed. Building data model converters is difficult, because often both syntactic and semantic data transformation is necessary. Moreover, data transformations use overall system performance, which may be a critical issue in particular during the operation phase.
For the engineering phase, two different approaches to solve these problems are known: (1) usage of a common or proprietary exchange data model and (2) usage of a metaengineering software application covering all aspects (in an optimal case) of the engineering phase.
The first approach provides an exchange data model that is understandable at least for pairs of software applications that need to communicate. The idea is to develop export and import interfaces at the boundaries of the different software applications that can transform the internal representation of data in the format of the exchange data model (export) and vice-versa (import). In general, such exchange data models and formats are defined bi-laterally on a proprietary basis. In certain domains (e.g., in the automotive industry) there exists a common exchange data model that can be used by all software applications. However, it should be noted in the engineering phase the use of an exchange data model can only decrease the number of inconsistencies but fails to eliminate them for several reasons. A main problem is that with loose coupling of the software applications by an exchange data model inconsistencies resulting from concurrent engineering in different software applications can generally not be avoided, because the engineering changes are isolated within the different software applications (i.e., concurrent changes are not synchronized automatically during engineering). Therefore, inconsistencies between multiple engineering software applications can only be detected through active communication. Moreover, while an exchange data model can help to detect inconsistencies through active communication, conflict resolution can only be done semi-automatically, i.e., with user-interaction. More specifically, in case of conflicts during import, it has to be decided which version to take (the local or the imported one). If the local version is selected, the transfer back to the other software application is not guaranteed and inconsistencies may last forever. If the imported version is selected, valuable and correct local data may be overwritten, because the engineer of the other software application might not be aware of the consequences in the second software application. Finally, the use of an exchange data model does not ensure communication with all relevant software applications has been taken place, i.e., all engineering software applications working on the same entities have received the notification of an update of the engineering data. However, to assure efficient, integrated engineering across all software applications, constant communication (including semi-automatic conflict resolution) of the engineering changes is necessary, leading to a considerable increase of the associated engineering costs.
The second approach to solve the above-mentioned problems is to provide a meta-engineering software application. The idea of a meta-engineering software application is to manage all aspects (in an optimal case) of the engineering phase in one place. To this end, meta-engineering software applications have a special proprietary data model, which is generic enough to allow modeling all aspects of the engineering phase.
This approach has several issues: First, in reality there is no meta-engineering software application that covers all aspects of the engineering phase. Therefore, the definition of an exchange data model for communication with the remaining software applications including the provisioning of corresponding interfaces is still necessary to cover all aspects of the engineering phase. This is particularly true for communication across the two lifecycle phases (i.e., communication of the results of engineering to operational systems and vice-versa). Second, for the special case of combined software applications supporting aspects of both the engineering as well as the plant operation phase (e.g., the applicant's Siemens DCS SPPA-T3000), meta-engineering software applications need to have the possibility to integrate or plug-in the business logic of the combined software application. Third, the generic approach of the meta-engineering software application leads to huge configuration efforts for the software application itself, both with respect to the internal data model and with respect to the corresponding business logic. Fourth, as there is no or nearly no generic data model of the meta-engineering software application itself available, the same meta-engineering software application needed in slightly different environments (e.g., differing by one subsystem or different plants even with the same software application chain) is configured differently, so that a data and library exchange between different installations is not possible. Fifth, multi-user configurations are problematic, as users who want to work on different aspects of an object, i.e., on attributes that are not shared between subsystems, are hindered, as normally the complete object is either locked or different versions are created, which have to be merged later. Finally, inconsistencies between the different software applications are not completely eliminated, because often small and fast needed changes (e.g., during commissioning) are made in the engineering software applications of the subsystems, because the ex- and import mechanism takes too long. In this case the second approach has the same problems as the first approach.